1. Technical Field
This invention relates to computer networks. More particularly, the invention relates to creating, maintaining, and executing application programs for one or more interconnected computers.
2. Description of the Prior Art
In the present state of the art, computer programmers typically link objects to create network applications. Commercial products, such as AVS (Advanced Visual Systems, Waltham, Mass.), apE (TaraVisual Corp., Columbus, Ohio--both described in K. W. Brodlie's book "Scientific Visualization," Springer-Verlag, Berlin Heidelberg, 1992), and Visual AppBuilder (in the AppWare product family from Novell in Provo, Utah) let an operator deposit objects, in the sense of object-oriented programming, onto a program workspace and link the objects in two ways. That is, the operator may draw lines between objects, thus representing the flow of information by messages; and other objects may access data contained in the object through a series of accessibility or scoping rules. A network application results from connecting objects into a diagram that looks and works like a flowchart.
The operator may specify the computer that is to run a particular object. For example, each object in the AVS system has a configuration screen where the operator can specify the name of a computer. The application uses the object on the specified computer when the program runs, conveying data over the network where necessary.
A separate class of tools manage the installation of software on a computer network. A typical installation tool lets the network administrator specify the latest version of application programs on a server. The next time each client computer restarts, for example the next morning when the computer users arrive at work, it checks the specification on the server and updates its files if necessary. These tools install software over a period of hours or days.
The prior art supports field maintenance of applications by shipping the object linking tool to the customer. The better object linking tools hide details about network programming and protocols. The requisite skills for exploiting these details are not normally present outside of professional software organizations. Thus, a user can only use the programming tool in the field to change the objects or their linkage.
No single system incorporates all of the foregoing methods. For example, a user can change the specification of which computer runs a particular object using AVS. However, the program fails if the object is not installed on the newly specified computer. Accordingly, the user has to use a software distribution tool to load the object onto that computer. Hours or days later, the object gets installed and the application runs again.
Spreadsheets let non-programmers set up and maintain applications, but only financial applications. By dropping two programming concepts from its interface (compared to AVS, apE, and Visual AppBuilder), a spreadsheet becomes acceptable to non-programmers. Objects, in the sense of object oriented programming, have both an internal state and a series of methods. To use objects, the operator must imagine the internal state of the computer and how that state is changed by executing methods. This is the same activity a programmer uses when writing instructions for a computer. Spreadsheet cells with constants have state but no method, whereas cells with formulae have a method but no state. As a result, the spreadsheet user need not understand programming concepts such as internal state, methods, and instructions. This makes the spreadsheet paradigm more appealing to non-programmers than the flowchart paradigm. For an explanation of the foregoing, see Rebecca Altman's book "Using 1-2-3 Release 4" (Que Corporation, 1993).
The parallel processing art offers an improvement on the installation process. In the parallel processing art, a programmer creates a single program for a group of computers. As a part of the program's design, only a subset of the statements or subroutines apply to any computer. On the other hand, the program does not need any external program or object to run. Starting a parallel program involves sending the program to all the computers in the group, thus circumventing any installation problem. The parallel processing art uses arcane programming methods, only works for one type of computer at a time, and ignores user interface issues that are very important in the rest of the industry. Additionally, parallel processing is typically concerned with installation across an integrated, interdependent architecture, and not with a network of diverse, independent processing elements. For further information on parallel processing see Michael J. Quinn's book "Parallel Computing: Theory and Practice," McGraw-Hill, New York.
Also of interest is prior art in the area of digital logic simulation on parallel computers. The simulation art uses a network of logic gates and wires as inputs. It simulates time-changing values on wires by events and uses simulation models to compute the behavior of a gate in response to input changes. In the distributed simulation art, each processor simulates gates that apply to its portion of the simulation, and sends events that affect other portions of the simulation to other computers as messages. Sophisticated algorithms determine when to delay a simulated entity because an action taking place concurrently on another computer might change one of its inputs. However, the simulation art has not been applied widely. For further information see D. Jefferson, "Virtual Time," ACM Transactions on Programming Languages, Volume 7, Number 3, July 1985, pp. 404-425; and K. M. Chandy and J. Misra, "Asynchronous Distributed Simulation via a Sequence of Parallel Computations," Communications of the ACM. Volume 24, Number 4, April 1981, pp. 198-206.